test(panic-profile): audit every workspace in the repo, not just the main one - #8147

main's panic-profile contract (#8147) is right to reject this: the
workspace builds a Perry runtime archive by path
(perry-next-runtime-provider -> perry-runtime) and its [profile.release]
declared no panic key, so it silently took cargo's default, unwind. A
runtime on unwind aborts the process on any JS throw crossing an
extern "C" helper with an interior Rust call (RFC 2945), and eh.rs's
transport is written for abort semantics — it steps the unwinder
through runtime frames without running cleanups, which is only sound
when there are none.

* fix(next): pass production app route dylib gate

* fix: address production app route review

* fix(runtime): root bound method construction

* fix(codegen): keep native statepoint roots in app dylibs

#8081 rebuilds the runtime's stack-map index at module init and
discovers compact GC maps in every loaded Mach-O/ELF image, so the
demotion of dylib artifacts to the shared shadow stack is obsolete —
and would leave provider apps running a lowering production never
ships (it also breaks the gc-native-roots provider gate, which
asserts the app map survives dead stripping). Drop
set_native_roots_for_artifact and pin the native lowering in the
entry test instead.

* fix(codegen): optnone post-RS4GC relocation-bloated functions

The #4880 opt-tier plan is computed from pre-rewrite sizes, but
rewrite-statepoints-for-gc's relocation fan-out grew one 51k-line
minified Next chunk closure 40x to 2.1M instructions, and a single -Os
function pass then ran 65+ CPU-minutes without finishing. Measured on
the #8036 fixture: the unit's IR went 27MB -> 581MB while its five
sibling units grew ~4x and compiled in 38-178s.

After the in-process rewrite, stamp optnone+noinline on any function
past 512k instructions (PERRY_LL_RS4GC_OPTNONE_INSTRS; largest
known-fine function is ~413k) so the pipeline skips exactly the
exploded functions and still optimizes their siblings; the stuck unit
now finishes default<Os> in ~21s. optnone gates only the middle-end,
so the statepoint lowering and compact GC map are unaffected. The
external text path re-parses the rewritten text and already re-derives
its opt tier from post-rewrite sizes.

* chore: split oversized files back under the 2000-line lint cap

The rebase re-inlined timer's drain_expired_tests (main had already
externalized the identical tests to timer/drain_expired_tests.rs) and
this PR's additions pushed object/mod.rs and cjs_wrap/mod.rs over the
cap. Restore main's external timer test file, move the call-method
depth guard family to object/call_method_depth.rs, and move cjs_wrap's
inline test module to cjs_wrap/tests.rs verbatim. Also register
PERRY_LL_RS4GC_OPTNONE_INSTRS as a build-cache key (#6394's rule,
caught by codegen_env_vars_are_build_cache_inputs).

* fix(codegen): reserve deep stacks for LLVM unit workers

The app-dylib compile SIGBUSed (no crash report) immediately after the
second optnone demotion fired, while an LLVM unit carrying a
multi-million-instruction post-RS4GC function was in flight on a
scoped worker with Rust's default 2 MiB stack. LLVM pass and ISel
recursion scales with function size, and a guard-page hit on a worker
thread presents exactly this way. Reserve 64 MiB per unit worker —
address space, not resident memory, until touched.

* fix(codegen): exempt the inline-asm loop barrier from RS4GC

rewrite-statepoints-for-gc wraps every non-leaf call in a gc function
into a gc.statepoint — including the empty `asm sideeffect` loop-
preservation barrier, whose statepoint form (`ptr elementtype(void ())
asm ...` as callee) is verifier-invalid: 'Cannot take the address of
an inline asm!'. The external opt path aborts on its verifier; the
in-process pipeline ran no post-rewrite verify, so the broken module
reached ISel and died as a bare KERN_PROTECTION_FAILURE SIGBUS with no
diagnostic (#8082, the jsonwebtoken unit of the Next production
fixture — reproduced twice at the same module).

Stamp "gc-leaf-function" on the barrier at all three emission sites
(text render, dialect text parse, dialect enum) — an empty asm can
never reach a safepoint, so the exemption is sound by construction —
and verify the module after the in-process rewrite so any future
RS4GC-invalid shape fails loudly instead of crashing the backend.
Regression tests cover both directions: the attributed barrier
survives unwrapped beside a still-statepointed real call, and the
unattributed shape is rejected, not miscompiled.

* fix(runtime): claim action-zero landing pads as Perry catches again

The review pass introduced a Handler/Cleanup discrimination keyed on
the LSDA call-site action, on the premise that Perry catch handlers
always carry a non-zero action. That premise is false under the
default native-roots build: retype_landing_pads_for_statepoints
(#7982) rewrites every catch-all pad whose {ptr,i32} payload is unused
— which is every JS catch pad — into `landingpad token cleanup`, and
LLVM emits a ZERO action for a cleanup clause. Phase one therefore
skipped every statepoint-built catch, the owned walker declined the
same pads, and a plain `try { throw } catch` aborted FATAL with 'no
landing pad'. The gate's Next server died on its first routine caught
manifest probe; a five-line reproducer confirms the abort under
default flags and the catch under PERRY_RS4GC=0.

It went unseen because the earlier revisions of this branch demoted
app dylibs to shadow frames (no statepoint retype in the fixture) and
no per-PR suite runs a compiled try/catch under native roots.

Restore the pre-review semantics — any pad in a Perry frame is the
armed JS catch — while keeping the review's transactional LSDA
parsing. The walker claims action-zero pads again, the personality
verdict comment explains why the action value must not discriminate,
and the inverted unit test pins the regression. Also adds
PERRY_EH_TRACE=1: one line per personality invocation (phase, owning
function via dladdr, ip offset, decoded pad), the instrument this
hunt lacked.

* docs: expand the changeset with the statepoint compile and EH fixes

* fix(runtime): root the generic array-like callback loops across their collection points

The forced-moving production gate faulted inside js_arraylike_map with
from-space protection armed: the loop derived the result array's
element pointer once, the callback's allocation ran a copying minor
that moved the array, and the next mapped element was written through
the pre-collection pointer into mprotect-poisoned retired from-space
(obj_type=1, the result array). Every callback-iteration helper in
array/generic.rs shared the shape: receiver, callback, result under
construction, and (in find/filter) the current element were all held
in raw locals across js_closure_call3/4 — and al_has/al_get, whose
getter and proxy paths run arbitrary JS, are collection points too.

Root all of them in a RuntimeHandleScope and re-read from the handles
at every use: forEach, map, filter, some, every, find, findIndex,
findLast, findLastIndex, reduce, reduceRight. The closure pointer is
re-derived from its rooted nanbox adjacent to each call instead of
being cached across iterations.

The regression test plants the gate's exact collection point — a
callback that runs a copying minor on every invocation — and asserts
the relocated receiver is observed and the mapped values land in the
relocated result. Sabotage-verified: re-hoisting the element pointer
makes it fail.

* fix(runtime): root call/apply and put-value locals across their JS invocations

The forced-moving gate faulted twice more in the same class: the
Function.prototype.call/.apply arms held the callee closure, the
explicit this, and the saved implicit-this bits in raw locals across
js_native_call_value, then handed the stale callee to
maybe_alias_explicit_this_construction; and js_put_value_set held the
receiver and property key across ordinary_set_with_receiver (which
runs user setters) before the array-subclass length note read the
stale receiver's header. Root all of them in RuntimeHandleScopes and
re-read from the handles after the calls.

* fix(ffi): transient GC roots for ext-crate callback snapshots

Ext crates keep user closures in handle-struct side tables that
registered scanners rewrite on a moving collection — but a SNAPSHOT of
those tables in a Rust local (a cloned listener Vec, a pending-request
struct parked in an mpsc channel between the hyper task and the pump
tick) is a copy no scanner can see. The forced gate faulted on both
shapes: a drained listener vec went stale after the first callback's
collection, and channel-parked handler/listener addresses went stale
across the microtask-pump safepoint minors that run while requests
wait.

Add an extern transient-root surface over the runtime-handle stack
(js_ffi_root_scope_enter/push/get/exit) plus a safe
perry_ffi::TransientRootScope wrapper, and convert perry-ext-http's
emit helpers, deferred-listen drain, close callback, and both
process_pending dispatchers. The HTTP/HTTPS dispatchers additionally
re-read handler and listener lists from the scanner-maintained server
handle at dispatch time instead of trusting the channel-parked
snapshot (the arrival-time is_check_continue routing decision is
kept).

* feat(gc): sharpen the from-space scan and stack-map walk instruments

- Bound the from-space scan's array walk by the LIVE length: capacity
  slack holds whatever bytes the allocator or a verbatim minor copy
  left there, and decoding it produced false MISSING-REWRITE aborts
  on the #8036 gate (a length-8/capacity-16 array whose slack held a
  dead method-table fragment).
- Append a payload preview to each offender report (classified words
  around the stale slot) so the owner identifies itself.
- PERRY_GC_STACKMAP_TRACE=1 prints each frame the native stack-map
  walk visits (ip + dladdr name); it is how the '7-frame truncated
  walk' hypothesis was falsified — those are complete walks at the
  microtask-pump boundary with no JS frames on the stack.

* chore: classify the bound-method test hook in the root-holder registry

TEST_BOUND_METHOD_MOVE is #[cfg(test)] diagnostic storage recording the
(before, after) addresses of a test-forced relocation; compared as
integers, never dereferenced, absent from shipped binaries.

* docs: extend the changeset with the rooting sweep and instruments

* feat(gc): name the HOLDERS of a stale from-space address, not just the consumer

The quarantine's fault report answers 'who used it' — the consumer,
which for a value read out of a table one instruction earlier is never
the bug. PERRY_GC_PROTECT_FROMSPACE_HOLDERS=1 adds the other half: a
whole-heap sweep at fault time for any live word that decodes to the
faulting address (or to the user pointer of the object that used to
live there), printed as owner/obj_type/offset.

Applied to #8036's forced-moving fault it is already decisive: NO arena
object holds the stale closure, so the holder is outside the GC heap —
a runtime side table, an FFI structure, or a frame slot — which is why
the whole-heap from-space scan could never name it.

Quarantined pages are skipped (they are PROT_NONE; reading one from the
handler would fault recursively) via a try_lock'd snapshot of the
registry, matching the census lookup above it. Also carries the
from-space scan's owner/target header dump, which is what identified
the earlier offenders as dead old-gen residue rather than live misses.

* fix(next): declare panic=abort in the provider workspace

main's panic-profile contract (#8147) is right to reject this: the
workspace builds a Perry runtime archive by path
(perry-next-runtime-provider -> perry-runtime) and its [profile.release]
declared no panic key, so it silently took cargo's default, unwind. A
runtime on unwind aborts the process on any JS throw crossing an
extern "C" helper with an interior Rust call (RFC 2945), and eh.rs's
transport is written for abort semantics — it steps the unwinder
through runtime frames without running cleanups, which is only sound
when there are none.

---------

Co-authored-by: Ralph Küpper <ralph@skelpo.com>